Amiga Collections: MegaDisc/MegaDisc 08 (1988)(MegaDisc Digital Publishing)(AU)[WB].zip/MegaDisc 08 (1988)(MegaDisc Digital Publishing)(AU)[WB].adf/ARTICLES/multitasking

Text File | 1988-05-28 | 17KB | 303 lines

          MULTITASKING AND THE AMIGA
                                          by Peter McKellar

   [Ed: Peter is a Consultant Systems Programmer in large IBM mainframe
       environments. He's also put together a MultiTasking Theme Disk
       pulling together material from various sources on this very
       important topic, including Pete Goodeve's IPC standards - see the
       end of the article. Many thanks, Pete.]

 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    People are often confused by the term "multitasking". This article will
 attempt to explain some terms for the novice.  If you are an experienced
 user there may also be a few points for you.

         Multitasking Comparison.
 It doesn't take a genius to see that the Amiga is a far superior machine
 to an IBM PC or clone.  We all know that an Amiga is better than a MAC or
 ATARI, both on price and performance.  But what is it that makes the Amiga
 really shine? Obviously, its multitasking capability alone makes it stand
 out from the opposition.  PC users claim that "MEMORY RESIDENT" programs
 permit them to run more than one thing at a time.  MAC users also claim
 that their machines permit more than one program to run at a time.  The
 ATARI user, whilst closest of all, claims multiple execution is possible.
 This is not true.  Multitasking, in the full meaning of the word, does not
 occur.

 None of these others can boast the power of the Amiga's true multitasking
 environment.  The term, "memory resident", simply means that a program has
 been preloaded into memory.  This means that it is occupying memory, lying
 dormant until branched to by a key-stroke. When this occurs the previously
 executing program loses control until another key-stroke combination is
 used.  An apt analogy would be to a large program with procedures that are
 branched to when certain keys are hit.  The only difference is that various
 parts of the program are sold by different suppliers.  Memory management
 becomes a problem when so many users want to share only 640K.  All the pro-
 grammers must agree upon where their code will reside.  The unfortunate
 truth is that most suppliers don't.  System crashes result when programs
 don't agree.  You often see suppliers giving the cryptic instructions:

                           "LOAD ME LAST"

 The basis for this is to ensure that memory doesn't get corrupted and that
 branch vectors are installed correctly.

 The MAC also relinquishes control of the CPU to another task when the user
 "clicks" on another icon, thereby selecting it for execution.  Everything
 else stops while the currently active task takes over, even if this task
 is awaiting input from the keyboard or serial port, or patiently sitting
 back while your slow old printer grinds out another line or two from the
 buffer.

 The ATARI is similar to the AMIGA in that multiple tasks can coexist and it
 does share some of the CPU cycles throughout different functions.  This is
 done on a fixed time, rotational, basis.  But tasks don't have a priority
 based scheduling system like the AMIGA.  I haven't undertaken a study of
 the ATARI, but I believe that the AMIGA supports a far more extensive lot
 of operating system calls.  I can't deny it - I'm just an AMIGA BIGOT!!!

 In theory, the new OS/2 system, for IBM PCs does offer some sophisticated
 multitasking capabilities.  But let's face it, there isn't any software
 around that uses any of the features.  It costs a fortune and won't run on
 less than one and a half meg.  That's the first release of OS/2, the full
 blown version, with graphics and all, will require 4 megabytes - just for
 the operating system (pretty hot, eh?).  The full-featured version is not
 yet available.  It's actually tied up in litigation from APPLE, and nobody
 is writing software for it until the court case is decided. As the case is
 simply a stalling action brought by APPLE, to cripple IBM's release of
 OS/2, it could possibly be dragged on for years.  In the meantime, this
 is an opportunity for the AMIGA to slip through and top sales over both.

 The AMIGA operating system is far superior to all of the systems now avail-
 able.  Its system displays the same techniques of multitasking that can be
 seen on high-end work stations right through to large mainframes.  The only
 real difference lies in the ability to recover from catastrophic errors.
 The AMIGA Operating System is likely to invoke Mr. Guru if you don't follow
 the rules properly.

 MULTITASKING OVERVIEW.
 As microprocessors become faster and faster, multitasking becomes more and
 more important.  Even with the superb custom chips installed in the AMIGA,
 I/O speed is a major contraint.  It is wasteful for the CPU to be idle as
 it waits for input or output operations to complete.  Any service that
 relies on some physical action (eg driving the electron guns that display
 text and graphics on the screen, or reading a disk) takes thousands of
 times longer to complete than the execution of programs within the CPU.
 It even takes longer to execute instructions that operate on RAM, rather
 than the data registers located on the microprocessor chip.

 Multitasking allows the processor to INITIATE one of these time-consuming
 activities (eg write to the disk) then promptly forget about it.  It can
 now move on to more productive activities, like playing a game, calculating
 pi to a million places, compiling a program, balancing your accounts and
 any other tasks that require your attention and computing power.  Each
 time one of these other tasks no longer requires CPU cycles, someone else
 gets a chance to use the processor.  More important tasks may also gain
 access to the CPU by forcing an interrupt.

 But how does the Operating System achieve such harmony, such a blissful
 and orderly sharing of resources?  By careful design and hardware support.
 Commodore have a priority-based task dispatching technique.  This is
 possible only if the software is well written and documented so the user
 (in this case, the programmer) can access required services (eg, read).
 The hardware must also permit interrupts, which stop the currently active
 task and allow the Operating System to reassign control of the CPU to a
 more deserving task.  The ability to interrupt a task makes this a
 "pre-emptive" Operating System.

 Only a task with a higher priority than the currently executing task can
 usurp control from the present task.  Tasks in the system with the same
 priority as that currently executing will still get to use the processor.
 Tasks of the SAME priority get to equally share CPU on a rotational basis.
 The operating system forces a time interval interrupt to ensure that one
 task doesn't hog the chip.

 If it wasn't for multitasking, the CPU would be idle for the greater part
 of its existence.  Multitasking allows the user to regain most of the power
 otherwise lost.  When higher priority tasks are waiting for resources other
 than CPU, lower priority tasks can execute. They will be interrupted and
 put on hold by those higher priority tasks when their wait condition is no
 longer outstanding (eg their I/O has completed).  When the higher priority
 task again waits, the lower priority task again gains control.  The same
 happens time and time again.

 INTERRUPTS.
 The term "interrupt" has been mentioned several times so far.  Maybe I need
 to clarify just what an interrupt is, and how they work.  Interrupts are
 first supported in the hardware of the Motorola 68000 microprocessor chip.
 The 68000 recognises any number of interrupts, but only seven priority
 levels are recognised.  Priority becomes important when multiple interrupts
 are in effect.  An example of when this will occur is when an interrupt is
 received from an external device (say a disk drive indicating it is ready
 to transmit data) and a program has tried to do a divide by zero.  The
 system must be able to distinguish who to service first, the program or the
 drive.  The Amiga's Operating System provides further discrimination with
 interrupts.  In conjuction with the Peripheral Interface Adapter chip, (the
 8520), and one of the custom chips, the 4703, up to 16 interrupt levels are
 provided.  The table below shows these.

    4703         CPU          Pseudo
    Name         Priority     Priority    Purpose
    NMI          7            15          Non-Maskable Interrupt
    INTEN        6            14          Special (Copper)
    EXTERN       6            13          8520B, external level 6
    DSKSYNC      5            12          Disk Byte
    RBF          5            11          Serial Input
    AUD1         4            10          Audio Channel 1
    AUD3         4            9           Audio Channel 3
    AUD0         4            8           Audio Channel 0
    AUD2         4            7           Audio Channel 2
    BLIT         3            6           Blitter Done
    VERTB        3            5           Vertical Blank
    COPER        3            4           Copper
    PORTS        2            3           8520A, external level 2
    TBE          1            2           Serial Output
    DSKBLK       1            1           Disk Block Done
    SOFTINT      1            0           Software Interrupts

 In our example, the standard CPU's seven priorities could have resolved the
 conflict.  A DSKSYNC would have been received at priority "5" and the zero
 divide would have generated a level 1 priority interrupt, ie SOFTINT.  But
 what if the COPPER and the BLITTER both generated an interrupt during a
 vertical blanking period interrupt?  Purists would recognise that this is
 an improbable, if not impossible situation, but serves only as an example.
 It does however demonstrate the neccessity of the extended interrupt
 priorities provided by the AMIGA's Operating System.

 DISPATCHING.
 Now that we realise what the custom chip's role is in assigning priorities,
 who will get dispatched first ? A task can be in one of 6 states , they
 are :
     1. Running
     2. Ready for execution
     3. Waiting on an external event
     4. Just added to the ready queue
     5. Being removed from the Task queue
     6. Awaiting special exception processing
 Items 4,5 and 6 are transient states and will not be discussed , The system
 maintains 2 queues of tasks that are not presently running. The first is
 sorted on priority and contains "ready tasks", those available to be
 dispatched.

 The second queue is a list of all tasks awaiting an external event (eg the
 completion of I/0). These are not held in priority order.  When an
 interrupt is generated (for example,when the I/O completes to a device),
 the queues are re-examined.  The task that was on the "not ready" queue,
 but whose I/O just completed, is requeued onto the "ready tasks" queue.
 This queue is then scanned from the head of the queue.  As this queue is
 sorted into priority order, the highest priority task will be found first.
 This will be dispatched.  The exception to this comes when a pre-specified
 "quantum" of time has expired.  When this happens, the next task of the
 same priority gets a chance to execute.  This time-slicing will continue,
 amongst the highest priority tasks, until a higher priority task is
 placed at the head of the "ready tasks" queue.

 Priorities can range between -128 (the lowest) to +127 (the highest).
 System tasks vary between -20 and +20. Zero priority should be used by
 user applications unless a special interaction with system tasks is
 required.

 USING MULTITASKING
 Multitasking can fall into one of 3 broad catergories.
     1. Stand alone processes
     2. Processes generated by another process
     3. Tasks generated by processes or other tasks

 STAND ALONE PROCESSES are what you generate if you run a batch file or
 command under CLI, or cause another window to be opened under WORKBENCH.
 A more common example would be having a clock active in your title bar,
 doing a background print of a file, and doing a directory list to your
 console.  This serialization of resouces may also require the program to
 wait (eg wait for keyboard input, letter by letter, of a command).  More
 waits will occur if both your directory listing, and your file print, need
 to use the disk drive at the same time.  This is a far more efficient way
 to use your machine than if you were to do each task in turn.  The actual
 elapsed time will be much less - who says there's no such thing as a free
 lunch?  I guess the only real cost is in CPU cycles required to service
 the dispatching cycle, maintaining the queues, and serializing access to
 physical devices like the disk drives.  These are all pretty meager costs
 compared to the savings.

 The more observant readers will have noticed that I used two terms before,
 TASK and PROCESS.  These are both features of multitasking but they work
 at different levels of the operating system.  Tasks work at a much lower
 level that Processes.

 Tasks are unable to perform DOS functions (eg producing output) and so a
 process may have to spawn another process if these facilities are required.
 The difference lies with a process being created through DOS, whereas a task
 is one level lower, being created by EXEC.  Consequently, if you want a
 technical reference for setting up a Process, you refer to the AmigaDOS
 Manual, put out by BANTAM.  The section of this manual titled "AmigaDOS
 Developer's Manual" (bottom of page 189 in my copy) will show you the
 syntax of a "LoadSeg" call, over the page is the "UnLoadSeg" call.  These
 calls load and unload segments of code for the express purpose of
 spawning new Processes.  The address of the code just loaded is referred
 to in the "CreateProc" call (page 187).

 Tasks are explained in the "ROM Kernel Reference Manual: Exec".  The two
 calls AddTask and RemTask are used to create tasks at the Exec level.  The
 calls rely on the correct initialization being performed.  All necessary
 information can be found in the Exec manual, and this is illustrated with
 many examples.  But if you're the lazy type like me, this won't be
 sufficient.  I NEED code, in machine readable format (ie on disk), and I
 have to know that it works.  For this reason I have scoured the FISH disks
 and found some interesting material.  Megadisc Theme disks are currently
 in preparation, specifically demonstrating task and process creation.
 Existing public domain offerrings are possibly a little cryptic, and don't
 always deliver what they promise.  I will be reworking these into a format
 suitable for distribution and append relevant documentation.  Megadisc will
 notify its readers when the disks become available.

 Follow-on articles will provide relevant code, comprehensively annotated,
 so that you too can write multitasking programs!!

 IPC
 On a slightly different track, I have just received word from Pete Goodeve
 (of XICON fame) in the USA.  He has been the leading light and inspiration
 for a new standard - "IPC".  This new and mysterious acronym is short for
 "Inter Process Communication". This standard will do for multitasking what
 IFF did for files.  The standard will permit different modules to talk a
 common language provided that all agree to follow the same conventions.

 But, you ask, why?  The possibilities are limitless.  It would be possible
 to mix'n'match commercial packages and public domain software.  The word
 processor of choice with your favourite spelling checker, a different
 printing package, and then send it all by modem to a friend - but all by
 the one program.  External interfaces with a database retrieval system
 could be all powerful.  Real time data capture by slave processes would
 be simple, your comms package could quietly lift data off a videotex
 system, pass it to one of a number of slave processes, depending on
 content.  Key values could be plugged into your spreadsheet: - by now
 you're starting to see the awesome power of such a standard??!!

 Pete and his co-workers had posted this standard on USENET in the USA and
 after much debate its form has stabilised.  The very first copy of the
 sample disk arrived in my letterbox only days ago, along with three
 catalogues and two bills.  No doubt you'll only be interested in the
 sample disk, so I've forwarded this to Megadisc, for packaging as a theme
 disk.

 If sufficient interest is shown, I will write some more on the standard in
 a future issue of Megadisc.  I suspect that we will hear far more about
 this new standard in the coming months.

 [Ed: Any programmer out there who is interested in this IPC development
 and wants to get Pete's disk, just call on [phone]. This initiative
 looks like it could out-hype HyperCard on the Mac, but like anything that
 starts, it needs support, especially from other countries. So anyone who
 needs a project, here it is. And Pete Goodeve is a most deserving person,
 not to mention capable - a bit of gossip, he tells me that WorkBench 1.3
 featured a XICON lookalike, with no attribution to him. After presenting
 his case to Commodore, they decided to change the name to ICONX...And
 anyway, it doesn't work on the 1.3 currently available. Anyway we
 continue to use the excellent XICON and are grateful to Pete for the
 support he showed from the very beginning.]

XXXXXXXXXXXXXXXXXXXXXXXXXXXX END OF MULTI-TASKING XXXXXXXXXXXXXXXXXXXXXXXXX